FDE_01_전방 배치 엔지니어가 끌린다

FDE(Forward Deployed Engineer)

FDE(Forward Deployed Engineer)라는 직무를 처음 알게 된 건 토스 채용 공고를 보면서였다. 이름은 낯설었는데 설명을 읽을수록 오히려 재밌다는 생각이 들었다.

다른 FDE 관련 글이나 다른 기업의 채용 공고도 같이 읽어보면서 나는 이 역할을 이렇게 이해하게 됐다.

현장의 복잡한 요구를 받아서 실제로 돌아가는 형태로 만들어내는 사람.

겉으로만 보면 파견 엔지니어 같기도 했고, SI나 컨설턴트 일과 비슷해 보이기도 했지만 좀 더 자세히 보니 조금 달라보였다.

운영만 하는 사람도 아니고, 연구 성과를 설명하는 사람도 아니었다.
애매한 요구를 정리하고 제한된 조건 안에서 작동하는 걸 만들어내는 역할에 더 가까웠다. 그래서 일종의 제너럴리스트처럼 느껴졌다.

나는 원래 이런 쪽이 더 재밌었다

나는 왜 개발자로 살고자 잘 다니던 직장을 때려치고 나왔을까.

생각해보면 나는 원래 컴퓨터가 좋았고 그걸로 뭘 할지, 뭘 만들 수 있는지 상상하는 걸 좋아하는 사람이었다. 어린 시절 내가 동경하던 사람들은 커뮤니티나 포럼에 자기가 만든 것들을 배포하는 사람들이었다. 대부분 게임 모더나 플러그인, 유틸리티 제작자들이었다.

특히 나는 모드나 플러그인 같은 개념을 정말 좋아했다. 졸업 논문도 모드와 관련된 걸 쓸 정도였다. 개발자가 처음부터 생각하지 못한 불편한 지점이나 더 있었으면 하는 것들을 다른 누군가가 발견해서 거기에 딱 맞는 걸 만들어 붙이는 일이 정말 대단해 보였다.

돌이켜보면 나는 그때부터 완전히 백지에서 뭔가를 발명하는 순간보다 이미 돌아가는 흐름에서 빈틈을 발견하고 필요한 걸 붙여 더 낫게 만드는 방식에 더 끌렸던 것 같다. 그리고 그 감각은 출판사에서 일하면서 더 또렷해졌다.

나는 프리랜서로 일하던 중 친한 선배의 도움으로 대형 출판사의 외주 작업을 하나 맡게 됐다. 그때 해당 팀의 팀장님과 직접 소통하며 일을 하던 도중 멋대로 몇 가지를 수정해서 '이게 더 잘 보일 것 같아서요.'라고 보낸 적이 있었다. 지금 생각하면 무슨 용기였나 싶다.

그러고 나서 무슨 이유에서인지 선배가 이력서를 한 번 넣어보라고 했다. 큰 의욕이 있던 건 아니었다. 프리랜서로 일하면서 수입이 들쭉날쭉하던 때라 제대로 준비도 못 한 채 얼떨결에 이력서를 냈다.

결과는 예상대로였다. 면접을 망쳤다. 아쉬운 마음에 선배와 술을 진탕 마시고 집에 왔는데, 어째서인지 덜컥 합격하고 말았다. 같은 시기에 면접을 본 출판 학교 출신의 의욕 넘치는 사람들도 있었는데, 그 사람들을 제치고 왜 내가 붙은 건지 한동안 잘 이해가 되지 않았다.

이후 시간이 조금 지나 술자리에서 이유를 여쭤보니 "요청하지 않아도 능동적으로 더 좋게 바꾸려고 하는 태도는 이미 편집자의 태도였다"는 말을 들었다. 외주 작업 한 번으로 그런 가능성을 봐주셨다는 게 고마웠다. 그 뒤로는 괜히 더 잘해야겠다는 마음이 들었다. 적어도 그런 식으로 일하는 사람은 되어야겠다고 생각했다. 스스로 말하긴 좀 민망하지만, 결과적으로는 팀 안에서 꽤 중요한 역할을 맡게 됐다.

돌이켜보면 나는 그냥 주어진 걸 깔끔하게 정리하는 데서 끝나는 사람은 아니었던 것 같다. 더 나은 방식이 보이면 그냥 지나치지 못했고, 원고를 더 좋게 다듬는 일이나 팀이 덜 힘들게 굴러가도록 손보는 일에서 더 큰 재미를 느꼈다. 아마 그 무렵 처음으로 "아, 나는 이런 식으로 일하는 사람이구나" 하는 감각이 조금씩 잡히기 시작했던 것 같다.

선배 팀원들이 하나둘 퇴사하고, 팀장님은 부서장으로, 이사님은 대표님으로 자리를 옮기면서 팀이 과부하되던 시기가 왔다. 나는 선임 편집자가 되어 팀장님을 좀 도와야 했는데, 그때 내 성향이 더 분명하게 드러났다. 남은 사람이 그때그때 버티는 방식으로는 답이 안 보였다. 그래서 구조를 좀 바꾸고 싶었다.

당시 소통은 사실상 구두 회의와 이메일에 묶여 있었는데 그 흐름이 너무 느리고 비효율적으로 느껴졌다. 그래서 내가 먼저 디스코드 도입을 제안했다. 그때 내 관심은 "새 툴을 써보자"가 아니라 흩어지는 정보를 한곳에 모으고 필요한 얘기가 바로 오가게 만드는 데 있었다.

거기서 멈추지 않고 디스코드 안에서 쓸 수 있는 AI 봇도 하나 만들어 붙였다. 지금처럼 AI 툴이 너무 당연한 시기는 아니었다. ChatGPT가 막 공개된 초기였고 나도 그때부터 엄청 많이 써봤다. 그냥 신기해서가 아니라 이걸 업무에 붙이면 실제로 뭐가 달라지는지 궁금했다.

개발을 제대로 배운 적은 없었으니 당연히 막히는 일도 많았다. ChatGPT에 이것저것 물어보고 안 되면 스택오버플로를 뒤지고 다시 고쳐보는 식이었다. 그렇게 조금씩 만들면서 개발도 같이 배웠다. 대단한 제품을 만든 건 아니었지만 팀이 바로 써볼 수 있는 도구는 됐다. 팀원들이 실제로 이걸 활용했고 팀장님도 나도 숨통이 조금은 트였다.

그때 더 확실해졌다. 나는 프로그램이나 자동화로 문제를 줄이는 일에 더 재미를 느끼는 사람이었다. 거창한 플랫폼을 설계하는 일보다, 누가 "이거 불편한데"라고 말한 지점을 보고 작게라도 해결책을 만드는 쪽에 더 끌렸다. 그리고 그걸 누군가가 실제로 써주면 좋았다.

대규모 유저가 몰리는 서비스도 물론 멋지지만 내 성향은 조금 다르다. 소수라도 정말 필요해서 쓰는 사람들이 있고, 그 사람들이 "이거 덕분에 편해졌다"라고 반응할 때 훨씬 크게 동기부여가 된다.

나는 사람이 더 열심히 버텨서 해결하는 구조보다 일이 굴러가는 방식 자체를 바꾸는 쪽에 더 관심이 많다. 반복되는 수고를 줄이고, 한 번 정리한 방식이 다음에도 계속 먹히게 만드는 것. FDE 설명을 읽었을 때 바로 눈에 들어온 것도 결국 이런 지점이었다.

블로그에 챗봇을 만든 이유

블로그에 RAG 챗봇을 붙인 것도 "AI 기술을 구현할 줄 안다"는 걸 보여주기 위해서가 아니었다. 출발점은 훨씬 단순했다. 내 블로그 콘텐츠가 이미 꽤 쌓여 있었는데 이걸 그냥 글 목록으로 두기보다 질문으로 꺼내 쓸 수 있으면 좋겠다고 생각했다.

핵심은 모델이 아니라 용도였다. "블로그 콘텐츠를 가지고 실제로 쓸 수 있는 챗봇을 만들자."는 목표가 먼저 있었고, 그다음에야 어떤 식으로 묶어야 할지 고민이 시작됐다.

그러다 보니 관심도 자연스럽게 한쪽으로 쏠렸다. 어떤 모델이 더 똑똑한지보다 어떻게 해야 이 시스템이 실제로 굴러가는지가 더 중요했다. 작은 서버에서도 버텨야 했고 불필요한 호출 비용은 줄여야 했고 엉뚱한 입력에는 가드레일도 필요했다. 제약이 많았지만 이상하게 그게 더 재밌었다.

나는 원래 이런 식으로 일하는 편이다. 큰 설계 담론을 오래 붙잡기보다 지금 당장 필요한 지식을 빠르게 모아 붙이고 짧은 피드백을 받으면서 고쳐나가는 쪽이 편하다. 프레임워크 자체를 만드는 것보다 이미 있는 프레임워크와 제한 사항 안에서 끝내 돌아가게 만드는 쪽이 내 성향에 더 잘 맞는다.

최근 만지는 작은 도구들도 비슷하다. Ship or Slop이나 Vibe Audit도 "이거 있으면 쓰겠다" 싶은 장면이 먼저 있었고 그다음에야 그걸 실제로 쓸 수 있는 형태로 바꾸는 식이었다. 결국 나한테 중요한 건 이름이나 기술보다 늘 필요와 사용 장면이다.

그래서 FDE가 낯설지 않았다

토스 공고를 보면서 처음 든 생각은 "새로운 직무를 발견했다"기보다 "내가 원래 좋아하던 일을 설명하는 이름을 찾았다"에 가까웠다. 다른 FDE 맥락을 더 읽어볼수록 그 생각은 더 강해졌다.

필요를 먼저 감지하고 그 필요를 기술로 옮기고, 복잡한 현실 조건 안에서 끝내 작동하게 만드는 일. 그리고 그 결과를 누군가가 실제로 잘 써주는 걸 보는 일. 내가 재미를 느끼는 지점이 정확히 여기에 있다.

실무 현장은 공고와 다르다는 것쯤은 나도 안다. 내 나이나 경력 같은 게 걸릴 수 있다는 것도 안다. 그래도 한 번 도전해보고 싶다. 그래서 이제 이런 내 사고방식을 실제 프로젝트로 증명해보고, 기록으로도 남겨보려고 한다.